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Titel: Verfahren zum Betreiben eines verteilten 

Rechnernetzwerks umfassend mehrere verteilt 
angeordnete Rechner 



B e s chr e ibung 

Die vorliegende Erfindung betrifft ein Verfahren . zum Betreiben 
eines verteilten Rechnernetzwerks umfassend mehrere verteilt 
angeordnete Rechner. Auf einem der Rechner ist mindestens eine 
auf einem Mikroprozessor des Rechners ablauffahige Komponente 
eines Computerprogramms angeordnet . Zum Betreiben des Rechners 
wird von einem kollozierten Klient oder einem entfernten 
Klient aus auf die Komponente zugegriffen. Der kollozierte 
Klient ist auf dem gleichen Rechner abgelegt und lauft 
innerhalb der gleichen Lauf zeitumgebung (sog. execution 
environment) ab wie die Komponente. Der entfernte Klient ist 



auf einem anderen Rechner abgelegt und/oder lauft innerhalb 
einer anderen Lauf zeitumgebung ab als die Komponente. 

Die Erfindung betrifft auSerdem ein Verfahren zum Betreiben 
eines Rechners eines verteilten Rechnernetzwerks umfassend den 
Rechner und mehrere weitere verteilt angeordnete Rechner. Auf 
dem Rechner ist mindestens eine auf einem Mikroprozessor des 
Rechners ablauffahige Komponente eines Compute rprogramms 
angeordnet. Zum Betreiben des Rechners wird von einem 
kollozierten Klient oder einem entfernten Klient aus auf die 
Komponente zugegriffen. 

Die Erfindung betrifft des weiteren ein auf Mikroprozessoren 
von Rechnern eines verteilten Rechnernetzwerks ablauf fahiges 
Computerprogramm. Das Computerprogramm weist mindestens eine 
Komponente mit mindestens einem Zugang zum Zugriff auf die 
Komponente von einem kollozierten Klient oder von einem 
entfernten Klient aus auf. 

Die vorliegende Erfindung betrifft aufierdem ein 
Speicherelement fur einen Rechner eines verteilten 
Rechnernetzwerks. Auf dem Speicherelement ist mindestens eine 
Komponente eines auf Mikroprozessoren von Rechnern des 
Rechnernetzwerks ablauf fahigen Computerprogramms 
abgespeichert . Das Computerprogramm weist mehrere Komponenten 
mit jeweils mindestens einem Zugang zum Zugriff auf die 
Komponente von einem kollozierten Klient oder entfernten 



Klient aus auf . Als Speicherelement kann insbesondere ein 
Read-only-Memory, ein Random- Access -Memory oder ein Flash- 
Memory zur Anwendung kommen. 

Die Erfindung betrifft auSerdem einen Rechner eines verteilten 
Rechnernetzwerks. Der Rechner umfasst ein Speicherelement, 
insbesondere ein Read- Only- Memory , ein Random- Access -Memory 
oder ein Flash-Memory, auf dem mindestens eine Komponente 
eines auf Mikroprozessoren von Rechnern des Rechnernetzwerks 
ablauf f ahigen Computerprogramms abgespeichert ist. Das 
Computerprogramm weist mehrere Komponenten mit jeweils 
mindestens einem Zugang zum Zugriff auf die Komponente von 
einem kollozierten Klient oder entfernten Klient aus auf. 

SchlieSlich betrifft die vorliegende Erfindung ein verteiltes 
Rechnernetzwerk umfassend mehrere Rechner. Die Rechner weisen 
jeweils ein Speicherelement, insbesondere ein Read-Only- 
Memory, ein Random -Access -Memory oder ein Flash-Memory, auf. 
Auf dem Speicherelement ist mindestens eine Komponente eines 
auf Mikroprozessoren der Rechner des Rechnernetzwerks 
ablauf f ahigen Computerprogramms abgespeichert. Das 
Computerprogramm weist mehrere Komponenten mit jeweils 
mindestens einem Zugang zum Zugriff auf die Komponente von 
einem kollozierten Klient oder entfernten Klient aus auf. 

Aus dem Stand der Technik sind verteilte Komponenten bspw. als 
sog. Enterprise Java Beans (EJB) oder Common Object Request 



Broker Architecture (CORBA) verteilte Objekte oder Komponenten 
bekannt. Bei den bekannten Verfahren zum Abarbeiten eines aus 
verteilten Komponenten aufgebauten Computerprogramms auf den 
Rechnern eines verteilten Rechnernetzwerks umfassen die 
einzelnen Komponenten jeweils verschiedene Funktionalitaten 
der Systemumgebung (z.B. EJB oder CORBA) und 
anwendungsspezif ische Funktionalitaten. Das verteilte 
Rechnernetzwerk besteht aus verschiedenen Rechnern oder 
Rechnerknoten. Auf einem Rechner oder Rechnerknoten ist 
mindestens eine Sof tware-Lauf zeitumgebung realisiert. Das 
Rechnernetzwerk hat bspw. eine Klient-Server-Architektur . 

Zur Ausfuhrung bestimmter anwendungsspezif ischer Funktionen im 
Rahmen der Abarbeitung des Computerprogramms kann ein Klient 
auf eine bestimmte Komponente, die die gewunschten 
anwendungsspezif ischen Funktionalitaten aufweist, zugreifen. 
Der Klient kann bspw. als eine weitere Komponente des gleichen 
Computerprogramms oder als ein beliebig anderes 
Computerprogramm ausgebildet sein. Wenn der Klient und die 
aufgerufene Komponente auf dem gleichen Rechner und innerhalb 
der gleichen Lauf zeitumgebung realisiert sind, greift der 
Klient auf die Komponente im Rahmen eines sog. kollozierten 
(collocated) Aufrufs zu. Das bedeutet, dass der Klient und die 
Komponente zwar lokal zueinander angeordnet sind, tatsachlich 
aber der Zugriff auf die Komponente praktisch wie ein sog. 
entfernter Zugriff behandelt wird. Anderenfalls greift der 
Klient im Rahmen eines entfernten (remote) Zugriffs auf die 



Komponente zu . Als Zugriff auf eine Komponente wird die 
Anforderung eines bestimmten Dienstes, der Aufruf einer 
Funktion oder Methode oder das Schicken einer Nachricht 
bezeichnet. Dabei konnen Parameter und/oder Ergebnisse 
iibertragen werden . 

Wie bereits erwahnt, wird bei dem Stand der Technik ein 
kollozierter Zugriff auf eine Komponente praktisch wie ein 
entfernter Zugriff behandelt. Ein entfernter Zugriff benotigt 
jedoch wesentlich mehr Abarbeitungszeit als ein lokaler 
Zugriff, da im Rahmen des entfernten Zugriff s u.a. 
Transformationen und Rucktransf ormationen von Inf ormationen 
zum Zwecke der Datemibertragung von dem einem Rechner, auf dem 
der Klient realisiert ist, zu einem weiteren Rechner des 
Rechnernetzwerks, auf dem die Komponente realisiert ist, 
durchgefuhrt werden miissen. Bei einem kollozierten Zugriff auf 
eine auf dem gleichen Rechner und in der gleichen 
Lauf zeitumgebung angeordnete Komponente konnen praktisch alle 
Funktionen, die fur einen entfernten Zugriff erforderlich 
sind, entf alien. 

Die Behandlung von kollizierten Zugriffen wie entfernte 
Zugriffe beim Stand der Technik hat ihre Ursache darin, dass 
die bekannten Komponenten uber eine entfernte Schnittstelle 
(sog. remote interface) mit lediglich einem entfernten Zugang 
(sog. remote gate) verfugen. Dadurch kann zwar eine 
Ortstransparenz (sog. location transparency) gewahrleistet 



werden, d. h. die gleiche Komponente kann ohne 
Umprogrammierung des Klienten sowohl kolloziert als auch 
entfernt aufgerufen werden. Eine Komponente mit 
Ortstransparenz kann reallokiert und ohne weiteres von einem 
lokalen auf einen entfernten Rechner bzw. Rechnernetzwerknoten 
und umgekehrt verlagert werden. Aufgrund der entfernten 
Schnittstelle miissen jedoch selbst kollozierte Zugriffe auf 
die Komponente iiber den entfernten Zugang erfolgen, d. h. 
nahezu wie entfernte Zugriffe behandelt werden und erfordern 
entsprechend viel Abarbeitungszeit . Ein zeitsparender lokaler 
Zugriff auf eine verteilte Komponente ist beim Stand der 
Technik also nicht moglich. 

Zwar werden bei den aus dem Stand der Technik bekannten 
Verfahren zum Betreiben eines Rechners oder eines 
Rechnernetzwerks beschrankte Optimierungen der kollozierten 
Zugriffe durchgef \ihrt . Durch diese Optimierungen kann die 
Zugriff szeit bei kollozierten Zugriff en gegeniiber entfernten 
Zugriffen zwar verringert werden, liegt jedoch immer noch urn 
GroSenordnungen iiber der fur einen lokalen Zugriff. 

Bei einer als Collocation Optimization bezeichneten 
Optimierung der kollozierten Zugriffe, wird bei einem 
kollozierten Zugriff auf eine Komponente der entfernte Zugang 
der Komponente umgangen und direkt in die Komponente 
gesprungen. AuSerdem fallt durch den direkten Zugriff auf die 
Komponente die Systemf unkt ionalitat des entfernten Zugangs weg 



und muS erst wieder durch spezielle Mafcnahmeri aufgerufen 
werden. Diese Optimierung ist weiterhin nicht fur Zugriffe auf 
Komponenten geeignet, bei denen Referenzen auf Komponenten als 
Parameter oder Ergebnisse ubergeben werden miissen. Bei dieser 
Optimierung verfugen die Komponenten also nur noch iiber eine 
beschrankte Ortstransparenz (location transparancy ) . 

Der vorliegenden Erfindung liegt deshalb die Aufgabe zugrunde, 
das Abarbeiten eines auf Mikroprozessoren von Rechnern eines 
verteilten Rechnernetzwerks ablauf fahigen Compute rprogramms 
mit mehreren Komponenten zu beschleunigen. 

Zur Losung dieser Aufgabe wird ausgehend von dem Verfahren zum 
Betreiben eines Rechnernetzwerks und von dem Verfahren zum 
Betreiben eines Rechners der eingangs genannten Art 
vorgeschlagen, dass auf die Komponente von dem kollozierten 
Klient aus iiber einen lokalen Zugang (local gate) der 
Komponente zugegriffen wird, falls der Klient auf dem gleichen 
Rechner abgelegt ist und innerhalb der gleichen 
Lauf zeitumgebung ablauf t wie die Komponente, und anderenfalls 
von dem entfernten Klient aus iiber einen entfernten Zugang 
(remote gate) der Komponente auf die Komponente zugegriffen 
wird. 

Die Komponenten weisen eine oder mehrere Schnittstellen (sog. 
interfaces) auf, wobei also fur jede Schnittstelle zwei 
getrennte Zugange (sog. gates) vorgesehen sind, ein lokaler 
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Zugang (sog. local gate) und ein entfernter Zugang (sog. 
remote gate) . Bei der Komponente sind die Funktionalitaten, 
die fur einen entfernten Zugriff erforderlich sind, (von dem 
entfernten Zugang bereitgestellt ) getrennt von den system- und 
anwendungsspezif ischen Funktionalitaten (von dem lokalen 
Zugang bereitgestellt) . Die Schnittstelle der Komponente ist 
vorzugsweise als eine lokale Schnittstelle ausgebildet . 

Mit dem erf indungsgemaSen Verfahren kann die Abarbeitungszeit 
eines beliebigen verteilten Computerprogramms mit mehreren 
Komponenten deutlich verringert werden. Das wird dadurch 
erzielt, dass kollozierte Zugriff e auf eine Komponente uber 
den lokalen Zugang erfolgen und als lokale Zugriffe behandelt 
werden. Bei dem lokalen Zugriff konnen die fur einen 
entfernten Zugriff erf orderlichen zeitraubenden Funktionen 
somit komplett entf alien. Durch die verringerte 
Abarbeitungszeit ergeben sich erhebliche Kostenvorteile, da 
entweder mit derselben Rechenleistung wesentlich komplexere 
Compute rprogramme oder mehr Transaktionen als bisher 
abgearbeitet werden konnen oder aber bei gleichbleibender 
Komplexitat der Compute rprogramme und Anzahl der Transaktionen 
die Rechenleistung der Rechner des Rechnernetzwerks reduziert 
werden kann. 

Bei dem erf indungsgemaSen Verfahren handelt es sich urn 
beliebig vielstufige Verfahren, d. h. von der aufgerufenen 
Komponente aus konnen nach dem vorgeschlagenen Prinzip weitere 
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Komponenten und von diesen wiederum weitere Komponenten u.s.w. 
aufgerufen werden. GemaS einer vorteilhaf ten Weiterbildung der 
vorliegenden Erfindung wird deshalb vorgeschlagen, dass von 
der Komponente aus auf mindestens eine weitere Komponente iiber 
einen lokalen Zugang der weiteren Komponente zugegriffen wird, 
falls die weitere Komponente auf dem gleichen Rechner abgelegt 
ist und innerhalb der gleichen Lauf zeitumgebung ablauft wie 
die Komponente und anderenfalls von der Komponente aus auf die 
J mindestens eine weitere Komponente iiber einen entf ernten 

Zugang der weiteren Komponente zugegriffen wird. 

Urn von einem kollozierten Klient (sog. collocated client) 
eines Rechnernetzwerks bspw. mit Client-Server-Architektur aus 
eine Komponente aufzurufen, greift der Klient iiber die 
Schnittstelle und den lokalen Zugang auf die Komponente zu, 
Innerhalb der Komponente werden dann die systemspezif ischen 
(z. B. EJB- oder CORBA-spez if ischen) Funktionalitaten und die 
~^ . anwendungsspezif ischen Funktionalitaten (die z. B. das 
^^'^ Ergebnis einer Rechenoperation oder den Ruckgabewert eines 
Funktionsauf ruf s berechnen) ausgef iihrt . 

Urn von einem entfernten Klient (remote client) des 
Rechnernetzwerks aus eine Komponente aufzurufen, greift der 
Klient iiber die Schnittstelle und den entfernten Zugang 
(remote gate) auf die Komponente zu. Von dem entfernten Zugang 
wird dann intern auf den lokalen Zugang (local gate) 
zugegriffen. Im Rahmen eines entfernten Zugriffs werden von 
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dem entfernten Zugang zunachst die fur den entfernten Zugriff 
erf orderlichen Funktionalitaten ausgefiihrt, bevor von dem 
lokalen Zugang die systemspezif ischen (z. B. EJB- oder CORBA- 
spezif ischen) Funktionalitaten ausgefiihrt werden. Dann erst 
werden schlieSlich die der Komponente zugeordneten 
anwendungsspezif ischen Funktionalitaten ausgefiihrt. 

GemaS einer bevorzugten Ausf iihrungsf orm der vorliegenden 
Erfindung wird iiber ein Proxy auf den entfernten Zugang der 
Komponenten zugegriffen, wobei das Proxy dieselbe 
Schnittstelle wie der lokale Zugang realisiert. Es wird also 
von einem Klient oder einer weiteren Komponente aus mittelbar 
liber das Proxy auf den entfernten Zugang der Komponente 
zugegriffen. Bei einem Zugriff auf die Komponente iiber eine 
lokale Schnittstelle, die das Proxy bereitstellt , muss das 
Proxy zunachst die lokale Schnittstelle in eine entfernete 
Schnittstelle zum Zugriff auf den entfernten Zugang umsetzen. 
Die lokale Schnittstelle der Komponente wird also zum einen 
von dem lokalen Zugang realisiert (technische Implementierung) 
und zum anderen von dem Proxy realisiert. 

Der Einsatz des Proxys fiihrt zwar theoretisch zu einer 
geringfiigig langeren Zugriffszeit auf entfernte Komponenten 
als beim Stand der Technik. Die zusatzliche Zugriffszeit ist 
jedoch, falls uberhaupt vorhanden, im Verhaltnis zu der 
Gesamtdauer eines entfernten Zugriffs vernachlassigbar gering 
und wird durch die deutlich verringerte Zugriffszeit bei 
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lokalen Zugriffen mehr als kompensiert . Im Mittel ergeben sich 
mit dem erf indungsgemaSen Verfahren fur die Abarbeitung von 
verteilten Compute rprogramme uber lokale und entfernte 
Zugriffe auf die Komponenten deutlich geringere 
Abarbeitungszeiten als beim Stand der Technik. 

GemaS dieser Ausf uhrungsf orm verfiigt ein Klient nicht uber 
eine direkte Referenz auf einen entfernten Zugang (remote 
gate) der Komponente bzw. wird er eine solche Referenz nicht 
benutzen, da sonst die Ortstransparenz (sog. location 
transparency) nicht mehr gegeben ware, sondern er hat eine 
Referenz auf ein Proxy, das selbst eine Referenz auf den 
entfernten Zugang enthalt. Das Proxy ist zwischen dem Klient 
und dem entfernten Zugang der auf zuruf enden Komponente 
vorgesehen, damit der Klient stets uber dieselbe Schnittstelle 
auf die Komponente zugreift, unabhangig davon uber welchen 
Zugang der Zugriff erfolgt, urn somit Ortstransparenz zu 
erhalten. 

Vorteilhaf terweise wird der entfernte Zugang der Komponente 
zur Transformation eines Parameters oder eines Ergebnisses 
eingesetzt, falls Dienste oder Funktionalitaten der Komponente 
Parameter oder Ergebnisse haben, die selbst eine Referenz auf 
eine weitere Komponente darstellen und die weitere Komponente 
bezuglich der Komponente zwar lokal, aber bezuglich des Klient 
entferht angeordnet ist. Wenn bspw. eine lokale Referenz auf 
eine erste Komponente an eine zweite Komponente weitergegeben 



werden soil, die nicht kolloziert ist, muss der entfernte 
Zugang die lokale Referenz in ein Proxy transf ormieren, das 
auf den entfernten Zugang der entsprechenden Komponente 
verweist. 

Des weiteren wird vorgeschlagen, dass ein Proxy zur 
Transformation eines Parameters oder eines Ergebnisses 
eingesetzt wird, falls Dienste oder Funktionalitaten der 
Komponente Parameter oder Ergebnisse haben, die selbst eine 
mittelbare Referenz iiber einen weiteren Proxy auf eine weitere 
Komponente darstellen und diese bezuglich der Komponente zwar 
entfernt, aber bezuglich des Klient kolloziert angeordnet ist. 
Dabei sind der Klient und die weitere Komponente in dem 
gleichen Rechner bzw. Rechnernetzwerkknoten und in der 
gleichen Lauf zeitumgebung angeordnet. 

GemaS einer anderen vorteilhaf ten Weiterbildung der 
vorliegenden Erfindung wird vorgeschlagen, dass zum Zugriff 
auf eine Komponente zunachst auf einen lokalen Namensdienst 
(sog. naming and directory service) zugegriffen und von diesem 
eine Referenz auf die aufzurufende Komponente iibergeben wird, 
wobei die Referenz auf einen lokalen Zugang der Komponente 
verweist, falls die aufzurufende Komponente eine kollozierte 
Komponente ist, und die Referenz evtl. iiber ein Proxy auf 
einen entfernten Zugang der Komponente verweist, falls die 
aufzurufende Komponente eine entfernte Komponente ist. Bei dem 
Namensdienst handelt es sich urn ein lokales Verzeichnis, in 



dem die Namen der Komponenten des Compute rprogramms und lokale 
Referenzen auf die Komponenten abgelegt sind. Aus den lokalen 
Referenzen konnen die entfernten Referenzen gewonnen werden. 
Die entfernten Referenzen konnen aber auch zusatzlich zu den 
lokalen Referenzen in dem Namensdienst abgelegt sein. 

GemaS einer weiteren bevorzugten Ausf uhrungsf orm der 
vorliegenden Erfindung wird vorgeschlagen, dass zum Zugriff 
auf eine Komponente zunachst auf einen lokalen Namensdienst 
zugegriffen und von diesem eine Referenz auf eine Fabrik (sog. 
factory) der auf zuruf enden Komponente iibergeben . wird, wobei 
die Referenz auf einen lokalen Zugang der Fabrik verweist, 
falls die Fabrik und die aufzurufende Komponente kolloziert 
sind, und die Referenz ggf . iiber ein Proxy auf einen 
entfernten Zugang der Fabrik verweist, falls die Fabrik und 
die aufzurufende Komponente entfernt sind, und von der Fabrik 
eine weitere Referenz auf die aufzurufende Komponente 
iibergeben wird, wobei die weitere Referenz auf einen lokalen 
Zugang der Komponente verweist, falls die Fabrik und die 
aufzurufende Komponente kollozierte sind, und die weitere 
Referenz ggf. iiber ein Proxy auf einen entfernten Zugang der 
Komponente verweist, falls die Fabrik und die aufzurufende 
Komponente entfernt sind. Bei EJB wird die Fabrik als Home- 
Interface bezeichnet. Eine Fabrik ist in der Regel 
erforderlich, wenn eine Komponente (z.B. Kontokomponente) mehr 
als eine Instanz (z.B. verschiedene Konten) aufweist. Die 
Referenzen aus dem lokalen Namensdienst miissen also nicht 



unbedingt unmittelbar auf einen lokalen oder iiber ein Proxy 
auf einen entfernten Zugang einer auf zuruf enden Komponente 
zeigen. Es ist vielmehr auch denkbar, dass die Referenzen 
zunachst auf die Fabrik der auf zuruf enden Komponente zeigen. 
Die Fabrik verfiigt ebenfalls iiber einen lokalen und eine 
entfernten Zugang. Je nach dem, ob die auf zuruf ende Komponente 
auf dem gleichen Rechner und in der gleichen Lauf zeitumgebung 
realisiert ist wie der auf ruf ende Klient oder nicht, zeigt die 
Referenz auf den lokalen bzw. ggf . iiber ein Proxy auf den 
entfernten Zugang der Fabrik. In der Fabrik sind weitere 
Referenzen auf die lokalen Zugange der entsprechenden 
Instanzen der auf zuruf enden Komponenten abgelegt. Aus den 
lokalen Referenzen konnen die entfernten Referenzen gewonnen 
werden. Die entfernten Referenzen konnen aber auch in der 
Fabrik abgelegt sein. Die Fabrik iibergibt entweder die lokale 
Referenz oder eine Referenz auf das Proxy an den aufrufenden 
Klient, der iiber die Referenz dann die auf zuruf ende Komponente 
auf ruf t. 

Als eine weitere Losung der Aufgabe der vorliegenden Erfindung 
wird ausgehend von dem Computerprogramm der eingangs genannten 
Art vorgeschlagen, dass die Komponente einen lokalen Zugang 
(local gate) zum Zugriff auf die Komponente von dem 
kollozierten Klient aus und einen entfernten Zugang (remote 
gate) zum Zugriff auf die Komponente von dem entfernten Klient 
aus auf weist . 



Die Komponente des erf indungsgemaSen Computerprogramms steht 
sowohl einem kollozierten als auch einem entfernten Klient zur 
Verfugung. Falls der Klient in dem gleichen Rechner bzw. 
Rechnernetzwerkknoten und in der gleichen Lauf zeitumgebung 
(sog. execution environment) angeordnet ist wie die 
aufzurufende Komponente, wird er als ein kollozierter Klient 
(sog. collocated client) bezeichnet. Falls der Klient in einem 
anderen Rechner bzw. Rechnernetzwerkknoten oder in einer 
anderen Lauf zeitumgebung angeordnet ist als die Komponente, 
wird er als ein entfernter Klient (sog. remote client) 
bezeichnet. Der entscheidende Vorteil des erf indungsgemaSen 
Computerprogramms besteht darin, dass aufgrund der besonderen 
Ausgestaltung der Schnittstelle der Komponente mit einem 
lokalen Zugang und einem entfernten Zugang echte lokale 
Zugriffe auf die Komponente uberhaupt erst moglich sind. Dabei 
handelt es sich im Unterschied zu den aus dem Stand der 
Technik bekannten kollozierten Zugriffen, die ahnlich wie 
entfernte Zugriffe betrachtet und abgearbeitet werden, urn 
echte lokale Zugriffe. Dadurch erfolgen lokale Zugriffe auf 
eine Komponente erheblich schneller und es ergeben sich 
deutlich kurzere Abarbeitungszeiten fur das Computerprogramm. 

Der Geschwindigkeitsvorteil bei einem lokalen Zugriff ergibt 
sich insbesondere dadurch, dass ein kollozierter Klient keine 
zusatzlichen fur einen entfernten Aufruf erf orderlichen 
Funktibnalitaten (sog. remote invocation overhead) ausfuhren 
muss, wenn auf die Komponente im Rahmen eines lokalen Zugriff s 



zugegriffen wird. Der lokale Zugang (local gate) umfasst alle 
systemspezif ischen (z. B. EJB- oder CORBA-spezif ischen) 
Funktionalitaten und verarbeitet Operat ionsauf ruf e von 
kollozierten Klienten (collocated clients) . Der entfernte 
Zugang (remote gate) umfasst alle fur einen entfernten Zugriff 
erf order lichen Funktionalitaten und verarbeitet Aufrufe von 
entfernten Klienten (remote clients) . Des weiteren verfugt das 
Compute rprogramm uber voile Ortstransparenz (sog. location 
transparency) . 

Das Computerprogramm kann auch mehrere Komponenten mit jeweils 
sowohl einem lokalen als auch einem entfernten Zugang 
aufweisen. Ebenso kann jede Komponente iiber mehrere 
Schnittstellen mit jeweils mehreren lokalen und entfernten 
Zugangen verfugen. Die Komponenten konnen in beliebigen 
verteilten Systemumgebungen, wie bspw. EJB oder CORBA # 
realisiert werden. Mit der vorliegenden Erfindung kann bei 
beliebigen Systemen der zusatzliche Aufwand fur die fur einen 
entfernten Aufruf erf orderliche Funktionalitaten (remote 
invocation overhead) bei kollozierten Zugriffen beseitigt 
werden . 

Als noch eine weitere Losung der Aufgabe der vorliegenden 
Erfindung wird ausgehend von dem Speicherelement der eingangs 
genannten Art vorgeschlagen, dass die Komponente einen lokalen 
Zugang (local gate) zum Zugriff auf die Komponente von dem 
kollozierten Klient aus und einen entfernten Zugang (remote 



gate) zum Zugriff auf die Komponente von dem entfernten Klient 
aus auf weist . 

Als noch eine weitere Losung der Aufgabe der vorliegenden 
Erfindung wird ausgehend von dem Rechner der eingangs 
genannten Art vorgeschlagen, dass die Komponente einen lokalen 
Zugang (local gate) zum Zugriff auf die Komponente von dem 
kollozierten Klient aus und einen entfernten Zugang (remote 
gate) zum Zugriff auf die Komponente von dem entfernten Klient 
aus auf weist. 

SchlieSlich wird als eine weitere Losung der Aufgabe der 
vorliegenden Erfindung ausgehend von dem Rechnernet zwerk der 
eingangs genannten Art vorgeschlagen, dass die Komponente 
einen lokalen Zugang (local gate) zum Zugriff auf die 
Komponente von dem kollozierten Klient aus und einen 
entfernten Zugang (remote gate) zum Zugriff auf die Komponente 
von dem entfernten Klient aus aufweist. 

Weitere Merkmale, Anwendungsmoglichkeiten und Vorteile der 
Erfindung ergeben sich aus der nachf olgenden Beschreibung von 
Ausf uhrungsbeispielen der Erfindung, die in der Zeichnung 
dargestellt sind. Dabei bilden alle beschriebenen oder 
dargestellten Merkmale fur sich oder in beliebiger Kombination 
den Gegenstand der Erfindung, unabhangig von ihrer 
Zusammenf assung in den Patentanspriichen oder deren 
Riickbeziehung sowie unabhangig von ihrer Formulierung bzw. 
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Darstellung in der Beschreibung bzw. in der Zeichnung. Es 
zeigen : 

Figur la ein Strukturdiagramm eines Aufrufs einer Komponente 
eines verteilten Compute rprogramms im Rahmen eines 
erf indungsgemaSen Verfahrens zum Abarbeiten des 
Compute rprogramms ; 

Figur lb ein Strukturdiagramm eines Aufrufs einer Komponente 
gemaS Figur la aus Sicht eines Klienten; 

Figur 2 ein Strukturdiagramm eines Aufrufs einer Komponente 
eines verteilten Computerprogramms im Rahmen eines 
aus dem Stand der Technik bekannten Verfahrens zum 
Abarbeiten des Computerprogramms; 

Figur 3a ein Strukturdiagramm eines Zugriffs auf eine 
kollozierte Komponente eines verteilten 
Computerprogramms iiber einen Namensdiest und eine 
Fabrik und einen lokalen Auf ruf ; 

Figur 3b ein Strukturdiagramm eines Zugriffs auf eine 
entfernte Komponente eines verteilten 
Computerprogramms iiber einen Namensdiest und eine 
Fabrik und einen entfernten Auf ruf ; 



Figur 4a ein erstes Szenario des erf indungsgemaSen Verfahrens 
mit einem kollozierten Klient und einer Referenz auf 
eine kollozierte Komponente; 

Figur 4b das Szenario aus Figur 4a mit einer Referenz des 
Klienten auf die kollozierte Komponente; 

Figur 5a ein zweites Szenario des erf indungsgemaSen 

Verfahrens mit einem kollozierten Klient und einer 
Referenz auf eine entfernte Komponente; 

Figur 5b das Szenario aus Figur 5a mit einer Referenz des 
Klienten auf die entfernte Komponente; 

Figur 6a ein drittes Szenario des erf indungsgemaSen 

Verfahrens mit eineni entfernten Klient und einer 
Referenz auf eine kollozierte Komponente ; 

Figur 6b das Szenario aus Figur 6a mit einer Referenz des 
Klienten auf die kollozierte Komponente ; 

Figur 7a ein viertes Szenario des erf indungsgemaSen 

Verfahrens mit einem entfernten Klient und einer 
Referenz auf eine entfernte Komponente; 

Figur 7b das Szenario aus Figur 7a mit einer Referenz des 
Klienten auf die entfernte Komponente; 



Figur 8a einen Sonderfall des vierten Szenarios aus Figur 7a 
mit einem entfernten Klient und einer Referenz auf 
eine entfernte Komponente, wobei die Komponente 
kolloziert zu dem Klient ist; und 

Figur 8b das Szenario aus Figur 8a mit einer Referenz des 
Klienten auf die kollozierte Komponente. 

Aus dem Stand der Technik sind Computerprogramme mit mehreren 
Komponenten bekannt, die einzeln oder zu mehreren auf verteilt 
angeordneten Rechnern eines Rechnernetzwerks z. B. mit einer 
Klient /Server-Architektur ablauffahig sind. Die Komponenten 
sind bspw. als sog. Enterprise Java Beans (EJB) oder als 
Common Object Request Broker Architecture (CORBA) verteilte 
Objekte oder Komponenten ausgebildet. Eine aus dem Stand der 
Technik bekannte Komponente 1 ist in Figur 2 dargestellt. Die 
Komponente 1 ist auf einem Rechner bzw. Rechennetzwerkknoten 2 
ydes Rechnernetzwerks innerhalb einer bestimmten Software- 
Lauf zeitumgebung angeordnet . Die Komponente 1 umfasst eine 
entfernte Schnittstelle (remote interface) 3 mit einem 
entfernten Zugang (remote gate) 4. 

Die Komponente 1 weist verschiedene von der Systemumgebung 
(z.B. EJB-spezif ische oder CORBA- spezifische Funktionen) 
bereitgestellte Funktionalitaten 5 und anwendungsspez if ische 
Funktionalitaten 6 auf, die den der Komponente 1 zugeordneten 
Funktionen entsprechen. AuSerdem umfasst die Komponente 1 fur 



einen entfernten Zugriff iiber den entfernten Zugang 4 
erf orderliche Funktionalitaten 7. Zur Ausfiihrung der 
anwendungsspezif ischen Funktionen der Komponente 1 im Rahmen 
der Abarbeitung des Compute rprogramms wird auf die Komponente 
1 von einem kollozierten Klient 8 oder einem entfernten Klient 
9 zugriff en. Wenn der Klient und die aufgerufene Komponente 1 
auf dem gleichen Rechner 2 und innerhalb der gleichen 
Lauf zeitumgebung realisiert sind, wird er als kollozierter 
(sog. collocated) Klient 8 bezeichnet. Anderenfalls wird der 
Klient als entfernter (sog, remote) Klient 9 bezeichnet. 

Auf die Komponente 1 kann mittels eines kollozierten Zugriffs 
(von dem kollozierten Klient 8 aus) oder mittels eines 
entfernten Zugriffs (von dem entfernten Klient 9 aus) 
zugegriffen werden. Ein Zugriff von einem entfernten Klient 9 
aus benotigt an sich wesentlich mehr Zeit als ein Zugriff von 
einem kollozierten Klient 8 aus, da im Rahmen des entfernten 
/Zugriffs u.a. fur einen entfernten Zugriff erf orderliche 
Funktionalitaten 7, insbesondere Transf ormationen und 
Riicktransf ormationen von Parametern und Ergebnissen zum Zwecke 
der Datenubertragung zwischen dem Rechner 2, auf dem die 
Komponente 1 realisiert ist, und einem Rechner 10, auf dem der 
Klient 9 angeordnet ist, durchgefiihrt werden miissen. Nach dem 
Stand der Technik miissen diese zusatzlichen Funktionalitaten 7 
selbst bei einem kollozierten Zugriff auf die Komponente 1 
ausgefiihrt werden, da kollozierte Zugriffe auf die Komponente 
1 uber den entfernten Zugang 4 erfolgen. Somit werden also 
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auch kollozierte Zugriffe praktisch wie entfernte Zugriffe 
behandelt und erfordern entsprechend viel Rechenzeit. 

Die in Figur la dargestellte Komponente 11 eines 
erf indungsgemaSen Compute rprogramms verfiigt dagegen uber 
mindestens eine lokale Schnittstelle (local interface) 12 mit 
jeweils zwei getrennten Zugangen, einem lokalen Zugang (local 
gate; L) 13 und einem entfernten Zugang (remote gate; R) 14. 
Der lokale Zugang 13 umfasst alle systemspezif ischen (z. B. 
EJB- oder CORBA-spezif ischen) Funktionalitaten 5 und 
verarbeitet Operationsauf ruf e von kollozierten Klienten 
(collocated clients) 8. Der entfernte Zugang 14 umfasst alle 
fur einen entfernten Zugriff erf orderlichen Funktionalitaten 7 
und verarbeitet Aufrufe von entfernten Klienten (remote 
clients) 9. 

Durch die zwei Zugange 13, 14 der Komponente 11 kann das 
j Abarbeiten eines auf Mikroprozessoren von Rechnern des 
verteilten Rechnernetzwerks ablauf f ahigen Compute rprogramms 
mit mehreren Komponenten deutlich beschleunigt werden. 
Erf indungsgemaS wird auf die Komponente 11 uber den lokalen 
Zugang 13 zugegriffen, falls die Komponente 11 auf dem 
gleichen Rechner 2 angeordnet ist wie der kollozierte Klient 
8. Anderenfalls wird von dem entfernten Klient 9 aus mittelbar 
uber den entfernten Zugang 14 auf die Komponente 11 
zugegriffen . 



Die Komponente 11 kann in beliebigen verteilten 

Systemumgebungen, wie bspw. EJB oder CORBA, realisiert werden. 
Bei beliebigen Systemen kann durch die Erfindung fur 
kollozierte Klienten der zusatzliche Aufwand fur die einen 
entfernten Aufruf erf orderlichen Funktionalitaten (remote 
invocation overhead) 7 beseitigt werden. Bei der Komponente 11 
sind also die Funktionalitaten 7, die fur einen entfernten 
Zugang erforderlich sind, getrennt von den systemspezif ischen 
Funktionalitaten 5 und den anwendungsspezif ischen 
Funktionalitaten 6. Die lokale Schnittstelle 12 wird zum einen 
von dem lokalen Zugang 13 realisiert (technische 
Implementierung) und zum anderen von einem Proxy 15 
realisiert. 

Urn von dem kollozierten Klient (collocated client) 8 aus die 
Komponente 11 aufzurufen, greift der Klient 8 liber die 
Schnittstelle 12 und den lokalen Zugang 13 unmittelbar auf die 
j Komponente 11 zu. Innerhalb der Komponente 11 werden dann die 
systemspezif ischen (z. B. EJB- oder CORBA- spez if ischen) 
Funktionalitaten 5 und die anwendungsspezif ischen 
Funktionalitaten 6 ausgef iihrt . Die fur einen entfernten 
Zugriff erf orderlichen Funktionalitaten 7 werden bei einem 
lokalen Zugriff auf die Komponente 11 nicht ausgef iihrt. 

Urn von dem entfernten Klient (remote client) 9 aus die 
Komponente 11 aufzurufen, greift der Klient 9 iiber die 
Schnittstelle 12 und das Proxy 15 auf den entfernten Zugang 



(remote gate) 14 zu. Dort werden die fur den entfernten 
Zugriff erf orderlichen Funktionalitaten 7 ausgefiihrt. Dann 
wird iiber einen internen Zugriff auf den lokalen Zugang 13 
zugegriffen. Dort werden dann die systemspezif ischen (z. B. 
EJB- oder CORBA-spezif ischen) Funktionalitaten 5 und die 
anwendungsspezif ischen Funktionalitaten 6 ausgefiihrt. 

Zwischen dem entfernten Zugang 14 und dem entfernten Klient 9 
ist das Proxy 15 vorgesehen, urn die lokale Schnittstelle 12 
fur den Klient 9 zu realisieren. Das Proxy 15 ist ein 
Schnittstellenumsetzer, der im vorliegenden Fall die lokale 
Schnittstelle 12 in eine entfernte Schnittstelle 31 umsetzt, 
damit der Klient 9 iiber die lokale Schnittstelle 12 auf den 
entfernten Zugang 14 der Komponente 11 zugreifen kann. Durch 
das Proxy 15 bleibt die Ortstransparenz (sog. location 
transparency) der Komponente 11 erhalten. 

Figur lb stellt die Figur la aus der Sicht des Klienten 8, 9 
^dar. Der Klient 8, 9 sieht die Komponente 11 und die lokale 
Schnittstelle 12, die stets dieselbe ist, unabhangig davon, ob 
sie direkt vom lokalen Zugang 13 oder iiber ein Proxy 15 und 
den entfernten Zugang 14 realisiert wird. 

In Figur 3a ist ein Diagramm eines Zugriffs auf eine 
kollozierte Komponente 11 des verteilten Computerprogramms mit 
zugehoriger Fabrik 19 mit dem kolloziertem Klienten 8 
dargestellt. Bei EJB wird die Fabrik auch als Home- Interface 



bezeichnet. Zunachst greift der kollozierte Klient 8 auf einen 
Namensdienst (sog. naming and directory service) 16 zu, der 
lokal zu dem Klient 8, d. h. auf dem gleichen Rechner 10 und 
innerhalb der gleichen Lauf zeitumgebung, angeordnet ist. Von 
dem Namensdienst 16 wird eine Kopie der Referenz 37 auf einen 
lokalen Zugang 38 der Fabrik 19 an den Klient 8 ubermittelt . 
Der Klient 8 halt diese als Referenz 39 zu der Fabrik 19 und 
ruft so ihre Dienste auf. Die Fabrik 19 halt eine Referenz 40 
auf den lokalen Zugang 13 der Komponente 11. Von der Fabrik 19 
wird eine Kopie der weiteren Referenz 40 auf den lokalen 
Zugang 13 der auf zuruf enden Komponente 11 an den Klient 8 
iibergeben. Dieser halt diese als weitere Referenz 41 und 
greift uber diese auf die Komponente 11 zu. 

In Figur 3b ist ein Diagramm eines Zugriffs auf eine entfernte 
Komponente 11 des verteilten Computerprogramms mit zugehoriger 
Fabrik 19 mit dem entfernten Klienten 9 dargestellt. Zunachst 
greift der entfernte Klient 9 auf den Namensdienst zu. Von dem 
Namensdienst 16 wird ein Proxy 15 mit einer Referenz 20 auf 
einen entfernten Zugang 18 der Fabrik 19 an den Klient 9 
ubermittelt. Der Klient 9 halt uber das Proxy 15 eine Referenz 
20 zu der Fabrik 19 und ruft so ihre Dienste auf. Die Fabrik 
19 halt eine Referenz 21 auf den entfernten Zugang 14 der 
Komponente 11. Von der Fabrik 19 wird ein Proxy 36 mit einer 
weiteren Referenz 22 auf den entfernten Zugang 14 der 
auf zuruf enden Komponente 11 an den Klient 9 ubermittelt. 



Dieser greift dann uber das Proxy 36 und die weitere Referenz 

22 auf die Komponente 11 zu. 

In den Figuren 4 bis 7 sind vier verschiedene Szenarien von 
lokalen oder entfernten Zugriffen auf die Komponente 11 und 
eine weitere Komponente 23 dargestellt. Die weitere Komponente 

23 verfugt ebenfalls einen lokalen Zugang 24 und einen 
entfernten Zugang 25. Die Komponente 11 erhalt von einem 
Klienten 8, 9 eine Referenz auf die weitere Komponente 23 
entweder als Ubergabeparameter eines Dienstauf ruf s oder gibt 
sie als Ruckgabeparameter oder als Ergebnis zuriick und muss 
ggf. eine Transformation durchfuhren. 

In dem ersten Szenario aus Figur 4a greift der kollozierte 
Klient 8 uber den lokalen Zugang 13 auf die Komponente 11 zu. 
Die weitere Komponente 23 ist in dem gleichen Rechner 2 bzw. 
in dem gleichen Rechnernetzwerkknoten und in der gleichen 
Lauf zeitumgebung wie die Komponente 11 angeordnet . Die 
Komponente 11 verfugt liber eine Referenz 2 6 auf den lokalen 
Zugang 24 der kollozierten weiteren Komponente 23 . Diese 
Referenz 2 6 wird an den bzw. von dem Klient 8 iibergeben, der 
uber eine Referenz 32 und den lokalen Zugang 24 auf die 
weitere Komponente 23 zugreift (vgl . Figur 4b). Bei dem ersten 
Szenario erfolgt also keine Transformation der 
Ref erenzparameter . 



In dem zweiten Szenario aus Figur 5a greift der kollozierte 
Klient 8 iiber den lokalen Zugang 13 auf die Komponente 11 zu. 
Die weitere Komponente 23 ist in einem anderen Rechner 27 bzw. 
in einem anderen Rechnernetzwerkknoten oder in einer anderen 
Lauf zeitumgebung als die Komponente 11 angeordnet. Die 
Komponente 11 verfiigt iiber eine Referenz 28 auf ein Proxy 29. 
Das Proxy 29 setzt die lokale Referenz 28 in eine entfernte 
Referenz 33 auf den entfernten Zugang 25 der entfernten 
weiteren Komponente 23 urn. Diese Referenz 2 8 wird an den bzw. 
von dem Klient 8 iibergeben, der iiber das Proxy 2 9 und eine 
Referenz 33 und den entfernten Zugang 25 auf die weitere 
Komponente 23 zugreift (vgl . Figur 5b). Bei dem zweiten 
Szenario erfolgt ebenfalls keine Transformation der 
Referenzparameter, da die weitere Komponente 23 sowohl 
beziiglich der Komponente 11 als auch beziiglich des Klient 8 
entfernt ist. Die Verbindung von dem Klient 8 zu der 
Komponente 11 muss nicht zwangslaufig weiter bestehen, wenn 
die Verbindung iiber die Referenz 33 aufgebaut ist. Statt iiber 
das Proxy 2 9 kann die Referenz 3 3 auch iiber einen anderen 
Proxy hergestellt werden. 

In dem dritten Szenario aus Figur 6a greift der entfernte 
Klient 9 iiber das Proxy 15 und den entfernten Zugang 14 auf 
die Komponente 11 zu. Die weitere Komponente 23 ist in dem 
gleichen Rechner 2 bzw. in dem gleichen Rechnernetzwerkknoten 
und in der gleichen Lauf zeitumgebung wie die Komponente 11 
angeordnet. Die Komponente 11 verfiigt iiber eine Referenz 26 
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auf den lokalen Zugang 24 der lokalen weiteren Koraponente 23. 
Wird die Referenz 26 an den bzw. von dem Klient 9 ubergeben, 
muss sie in eine bzw. aus einer Referenz auf ein Proxy 30, das 
uber die Referenz 34 und den entfernten Zugang 25 auf die 
weitere Komponente 23 zugreift (vgl . Figur 6b), transf ormiert 
werden. Bei dem dritten Szenario werden die Ref erenzparameter 
in dem entfernten Zugang 14 transf ormiert , da die weitere 
Komponente 23 bezviglich der Komponente 11 zwar lokal, aber 
bezuglich des Klient 9 entfernt ist. Die Ref erenzparameter 
werden also von dem entfernten Zugang 14 von lokal zu entfernt 
bzw. umgekehrt transf ormiert . Die Verbindung von dem Klient 9 
uber das Proxy 15 zu der Komponente 11 muss nicht zwangslaufig 
weiter bestehen, wenn die Verbindung uber das Proxy 3 0 
auf gebaut ist . 



In dem vierten Szenario aus Figur 7a greift der entfernte 
Klient 9 uber das Proxy 15 und den entfernten Zugang 14 auf 
die Komponente 11 zu. Die weitere Komponente 23 ist in einem 
anderen Rechner 27 bzw. in einem anderen Rechnernetzwerkknoten 
Oder in einer anderen Lauf zeitumgebung als die Komponente 11 
angeordnet. Die Komponente 11 verfugt tiber eine Referenz 28 
auf ein Proxy 29. Dieser setzt die Referenz 28 in eine 
Referenz auf den entfernten Zugang 25 der entfernten weiteren 
Komponente 2 3 urn. Diese Referenz 28 wird an den bzw. von dem 
Klient 9 ubergeben, der iiber ein Proxy 30, eine Referenz 35 
und den entfernten Zugang 25 auf die weitere Komponente 23 
zugreift (vgl. Figur 7b). Bei dem vierten Szenario erfolgt 



keine Transformation der Referenzparameter, da die weitere 
Komponente 23 sowohl bezuglich der Komponente 11 als auch 
bezuglich des Klient 9 entfernt ist . Die Verbindung von dem 
Klient 9 uber das Proxy 15 zu der Komponente 11 muss nicht 
zwangslaufig weiter bestehen, wenn die Verbindung uber die 
Referenz 35 aufgebaut ist. 

In Figur 8a ist ein Sonderfall des in den Figuren 7a und 7b 
dargestellten vierten Szenarios dargestellt, bei dem die 
weitere Komponente 23 zwar entfernt bezuglich der Komponente 
11/ aber kolloziert bezuglich des Klient 9 angeordnet ist, 
d. h. der Klient 9 und die weitere Komponente 23 in dem 
gleichen Rechner 10 bzw. Rechnernetzwerkknoten und in der 
gleichen Lauf zeitumgebung angeordnet sind. In diesem Fall muss 
das Proxy 15 entfernte Referenzparameter oder Ergebnisse von 
Operationen in lokale transf ormieren bzw. umgekehrt, damit der 
Klient 9 uber den lokalen Zugang 24 auf die weitere Komponente 
23 zugreifen kann. 

Wenn bspw. das Proxy 15 eine Operation an dem entfernten 
Zugang 14 der Komponente 11 ausgelost hat und als Ergebnis 
eine Referenz auf das Proxy 29 erhalt, sollte es die entfernte 
Referenz in eine lokale Referenz umwandeln und eine lokale 
Referenz iibergeben. Der Klient 9, der die Referenz auf das 
Proxy 2 9 erhalt, wiirde auch ohne eine Transformation der 
Referenz richtig arbeiten, fur den Zugriff auf die weitere 
Komponente 23 jedoch wesentlich langer brauchen, da der 



Zugriff auf die weitere Komponente 23 als ein entfernter 
Zugriff bearbeitet wurde . Ohne eine Transformation der 
Referenz miissten zusatzliche, zeitraubende fur einen 
entfernten Aufruf erf orderliche Funktionalitaten (sog. remote 
invocation overhead) ausgefiihrt werden, obwohl der Klient 9 
und die weitere Komponente 23 lokal angeordnet (collocated) 
sind. Urn dies zu verhindern, transf ormiert das Proxy 15 die 
Referenz auf den Proxy 2 9 in eine lokale Referenz und ubergibt 
diese an den Klient 9. 
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Patentansprxiche 

1. Verfahren zum Betreiben eines verteilten Rechnernetzwerks 
umfassend mehrere verteilt angeordnete Rechner (2, 10, 
27) , wobei auf einem der Rechner (2) mindestens eine auf 
einem Mikroprozessor des Rechners (2) ablauffahige 
Komponente (11) eines Compute rprogramms angeordnet ist 
und zum Betreiben des Rechners (2) von einem kollozierten 
Klient (8) oder einem entfernten Klient (9) aus auf die 
Komponente (11) zugegriffen wird, dadurch gekennzeichnet , 
dass auf die Komponente (11) von dem kollozierten Klient 

(8) aus uber einen lokalen Zugang (local gate, 13) der 
Komponente (11) zugegriffen wird, falls der Klient (8) 
auf dem gleichen Rechner (2) abgelegt ist und innerhalb 
der gleichen Lauf zeitumgebung ablauft wie die Komponente 

(11) , und anderenfalls von dem entfernten Klient (9) aus 
uber einen entfernten Zugang (remote gate, 14) der 
Komponente (11) auf die Komponente (11) zugegriffen wird. 

2. Verfahren zum Betreiben eines Rechners (2) eines 
verteilten Rechnernetzwerks umfassend den Rechner (2) und 
mehrere weitere verteilt angeordnete Rechner (10, 27), 
wobei auf dem Rechner (2) mindestens eine auf einem 
Mikroprozessor des Rechners (2) ablauffahige Komponente 
(11) eines Computerprogramms angeordnet ist und zum 
Betreiben des Rechners (2) von einem kollozierten Klient 



(8) oder einem entfernten Klient (9) aus auf die 
Komponente (11) zugegriffen wird, dadurch gekennzeichnet, 
dass auf die Komponente (11) von dem kollozierten Klient 

(8) aus iiber einen lokalen Zugang (local gate, 13) der 
Komponente (11) zugegriffen wird, falls die Komponente 
(11) auf dem gleichen Rechner (2) abgelegt ist und 
innerhalb der gleichen Lauf zeitumgebung ablauft wie der 
Klient (8) , und anderenfalls von dem entfernten Klient 

(9) aus iiber einen entfernten Zugang (remote gate, 14) 
der Komponente (11) auf die Komponente (11) zugegriffen 
wird. 

Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, 
dass von der Komponente (11) aus auf mindestens eine 
weitere Komponente (23) iiber einen lokalen Zugang (24) 
der weiteren Komponente (23) zugegriffen wird, falls die 
weitere Komponente (23) auf dem gleichen Rechner (2) 
abgelegt ist und innerhalb der gleichen Lauf zeitumgebung 
ablauft wie die Komponente (11) und anderenfalls von der 
Komponente (11) aus auf die mindestens eine weitere 
Komponente (23) iiber einen entfernten Zugang (25) der 
weiteren Komponente (23) zugegriffen wird. 

Verfahren nach einem der Anspriiche 1 bis 3, dadurch 
gekennzeichnet, dass iiber ein Proxy (15, 29, 30) auf den 
entfernten Zugang (14, 25) der Komponenten (11, 23) 



zugegriffen wird, wobei das Proxy (15, 29, 30) dieselbe 
Schnittstelle (12) wie der lokale Zugang (13) realisiert. 

Verfahren nach Anspruch 3 oder 4, dadurch gekennzeichnet , 
dass der entfernte Zugang (14) der Komponente (11) zur 
Transformation eines Parameters oder eines Ergebnisses 
eingesetzt wird, falls Dienste oder Funktionalitaten der 
Komponente (11) Parameter oder Ergebnisse haben, die 
selbst eine Referenz (26) auf die weitere Komponente (23) 
darstellen und die weitere Komponente (23) beziiglich der 
Komponente (11) zwar lokal, aber beziiglich des Klient (9) 
entfernt angeordnet ist. 

Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass 
ein Proxy (15) zur Transformation eines Parameters oder 
eines Ergebnisses eingesetzt wird, falls Dienste oder 
Funktionalitaten der Komponente (11) Parameter oder 
Ergebnisse haben, die selbst eine Referenz (28) auf ein 
weiteres Proxy (29) darstellen und die weitere Komponente 
(23) beziiglich der Komponente (11) zwar entfernt, aber 
beziiglich des Klient (9) kolloziert angeordnet ist. 

Verfahren nach einem der Anspriiche 1 bis 6, dadurch 
gekennzeichnet, dass zum Zugriff auf eine Komponente (11, 
23) zunachst auf einen lokalen Namensdienst (16) 
zugegriffen und von diesem eine Referenz (41, 42) auf die 
aufzurufende Komponente (11, 23) iibergeben wird, wobei 



die Referenz (41) auf einen lokalen Zugang (13, 24) der 
Komponente (11, 23) verweist, falls die aufzurufende 
Komponente (11, 23) eine kollozierte Komponente ist, und 
die Referenz (42) ggf . iiber einen Proxy (36) auf einen 
entfernten Zugang (14, 25) der Komponente (11, 23) 
verweist, falls die aufzurufende Komponente (11, 23) eine 
entfernte Komponente ist. 

Verfahren nach Anspruch 7, dadurch gekennzeichnet , dass 
zum Zugriff auf eine Komponente (11, 23) zunachst auf 
einen lokalen Namensdienst (16) zugegriffen und von 
diesem eine Referenz (17, 37) auf eine Fabrik (19) der 
auf zuruf enden Komponente (11, 23) ubergeben wird, wobei 
die Referenz (37) auf einen lokalen Zugang (38) der 
Fabrik (19) verweist, falls die Fabrik (19) und die 
aufzurufende Komponente (11, 23) kolloziert sind, und die 
Referenz (17) ggf. in ein Proxy (15) verpackt auf einen 
entfernten Zugang (18) der Fabrik (19) verweist, falls 
die Fabrik (19) und die aufzurufende Komponente (11, 23) 
entfernt Komponente sind, und von der Fabrik (19) eine 
weitere Referenz (21, 40) auf die aufzurufende Komponente 
(11, 23) ubergeben wird, wobei die weitere Referenz (40) 
auf einen lokalen Zugang (13, 24) der Komponente (11, 23) 
verweist, falls die Fabrik (19) und die aufzurufende 
Komponente (11, 23) kolloziert sind, und die weitere 
Referenz (21) ggf. in ein Proxy (3 6) verpackt auf einen 
entfernten Zugang (14, 25) der Komponente (11, 23) 



verweist, falls die Fabrik (19) die aufzurufende 
Komponente (11, 23) entfernt sind. 

Auf Mikroprozessoren von Rechnern (2, 10, 27) eines 
verteiltert Rechnernetzwerks ablauf fahiges 
Computerprogramm umfassend mindestens eine Komponente 

(11) mit mindestens einem Zugang zum Zugriff auf die 
Komponente (11) von einem kollozierten Klient (8), der 
auf dem gleichen Rechner (2) abgelegt ist und innerhalb 
der gleichen Lauf zeitumgebung ablauf t wie die Komponente 

(11) , oder von einem entfernten Klient (9) aus, der auf 
einem anderen Rechner (10) abgelegt ist und/oder 
innerhalb einer anderen Lauf zeitumgebung ablauft als die 
Komponente (11) , dadurch gekennzeichnet , dass die 
Komponente (11) einen lokalen Zugang (local gate, 13) zum 
Zugriff auf die Komponente (11) von dem kollozierten 
Klient (8) aus und einen entfernten Zugang (remote gate, 
14) zum Zugriff auf die Komponente (11) von dem 
entfernten Klient (9) aus auf weist . 

Speicherelement , insbesondere Read-Only-Memory, Random- 
Access -Memory oder Flash-Memory, fur einen Rechner (2, 
10, 27) eines vefteilten Rechnernetzwerks, auf dem 
mindestens eine Komponente (11) eines auf 
Mikroprozessoren von Rechnern (2, 11, 27) des 
Rechnernetzwerks ablauf fahigen Computerprogramms 
abgespeichert ist, wobei die Komponente (11) mindestens 



einen Zugang zum Zugriff auf die Komponente (11) von 
einem kollozierten Klient (8) aus aufweist, der auf dem 
gleichen Rechner (2) abgelegt ist und innerhalb der 
gleichen Lauf zeitumgebung ablauft wie die Komponente 
(11), oder von einem entfernten Klient (9) aus, der auf 
einem anderen Rechner (10) abgelegt ist und/oder 
innerhalb einer anderen Lauf zeitumgebung ablauft als die 
Komponente (11) , dadurch gekenxizeichnet , dass die 
Komponente (11) einen lokalen Zugang (local gate, 13) zui 
Zugriff auf die Komponente (11) von dem kollozierten 
Klient (8) aus und einen entfernten Zugang (remote gate, 
14) zum Zugriff auf die Komponente (11) von dem 
entfernten Klient (9) aus aufweist. 

Rechner eines verteilten Rechnernetzwerks mit einem 
Speicherelement , insbesondere einem Read- Only -Memory, 
einem Random- Ac cess -Memory oder einem Flash-Memory, auf 
dem mindestens eine Komponente (11) eines auf 
Mikroprozessoren von Rechnern (2, 11, 27) des 
Rechnernetzwerks ablauf f ahigen Computerprogramms 
abgespeichert ist, wobei die Komponente (11) mindestens 
einen Zugang zum Zugriff auf die Komponente (11) von 
einem kollozierten Klient (8) aus aufweist, der auf dem 
gleichen Rechner (2) abgelegt ist und innerhalb der 
gleichen Lauf zeitumgebung ablauft wie die Komponente 
(11) , oder von einem entfernten Klient (9) aus, der auf 
einem anderen Rechner (10) abgelegt ist und/oder 



innerhalb einer anderen Lauf zeitumgebung ablauft als die 
Komponente (11) , dadurch gekennzeichnet , dass die 
Komponente (11) einen lokalen Zugang (local gate, 13) zur 
Zugriff auf die Komponente (11) von dem kollozierten 
Klient (8) aus und einen entfernten Zugang (remote gate, 
14) zura Zugriff auf die Komponente (11) von dem 
entfernten Klient (9) aus aufweist. 

Verteiltes Rechnernetzwerk umfassend mehrere Rechner (2, 
10, 27) mit jeweils einem Speicherelement , insbesondere 
einem Read-Only-Memory, einem Random-Access -Memory oder 
einem Flash-Memory, auf dem mindestens eine Komponente 
(11) eines auf Mikroprozessoren von Rechnern (2, 11, 27) 
des Rechnernetzwerks ablauf f ahigen Computerprogramms 
abgespeichert ist, wobei die Komponente (11) mindestens 
einen Zugang zum Zugriff auf die Komponente (11) von 
einem kollozierten Klient (8) aus aufweist, der auf dem 
gleichen Rechner (2) abgelegt ist und innerhalb der 
gleichen Lauf zeitumgebung ablauft wie die Komponente 
(11) , oder von einem entfernten Klient (9) aus, der auf 
einem anderen Rechner (10) abgelegt ist und/oder 
innerhalb einer anderen Lauf zeitumgebung ablauft als die 
Komponente (11) , dadurch gekennzeichnet, dass die 
Komponente (11) einen lokalen Zugang (local gate, 13) zum 
Zugriff auf die Komponente (11) von dem kollozierten 
Klient (8) aus und einen entfernten Zugang (remote gate, 
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14) zum Zugriff auf die Komponente (11) von dem 
entfernten Klient (9) aus auf weist . 
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Zusammenf assung 

Die Erfindung betrifft ein Verfahren zum Betreiben eines 
verteilten Rechnernetzwerks. Das Rechnemetzwerk weist mehrere 
verteilt angeordnete Rechner (2 , 10 , 27) auf, wobei auf einem 
der Rechner (2) eine auf einem Mikroprozessor des Rechners (2) 
ablauffahige Komponente (11) eines Computerprogramms 
' ^ angeordnet ist. Zum Betreiben des Rechners (2) wird von einem 
kollozierten Klient (8) oder einem entfernten Klient (9) aus 
auf die Komponente (11) zugegriffen. Urn das Abarbeiten des 
Computerprogramms zu beschleunigen, wird vorgeschlagen, dass 
auf die Komponente (11) von dem kollozierten Klient (8) aus 
iiber einen lokalen Zugang (local gate, 13) der Komponente (11) 
zugegriffen wird, falls die Komponente (11) auf dem gleichen 
Rechner (2) abgelegt ist und innerhalb der gleichen 
Lauf zeitumgebung ablauft wie der Klient (8) , und anderenfalls 
v on dem entfernten Klient (9) aus ggf . iiber ein Proxy iiber 
einen entfernten Zugang (remote gate, 14) der Komponente (11) 
auf die Komponente (11) zugegriffen wird. (Figur 1) 
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